yannick

Quand il s'agit d'installer un serveur DNS, que ce soit un résolveur ou un serveur faisant autorité, les yeux se tournent systématiquement vers Bind. C'est souvent un choix fait "par défaut" ou parce que c'est celui qui est enseigné en cours et qu'il fait à la fois résolveur et serveur faisant autorité. Cependant il existe bien d'autres logiciels pour servir des zones comme Knot, PowerDNS ou NSD et c'est ce dernier que j'utilise.

Dans cet article je vais prendre pour exemple la zone lithio.fr.

Les glue records

Pour commencer il faut dire à la zone parent qui sont les serveurs DNS faisant autorité sur notre zone en créant des Glue Records.

Parler de Glue Record dans un cours c'est en général un bon moyen de voir si les étudiant⋅e⋅s suivent. On énonce :

"Et donc la zone parent annonce que le DNS faisant autorité pour example.com est ns1.example.com"

et on voit ce qui se passe. Il y en a en général un⋅e pour dire :

"Mais si le parent dit que le DNS qui fait autorité pour example.com c'est ns1.example.com alors il faut résoudre le nom de ns1.example.com, sauf que c'est justement ns1.example.com qui a cette info !"

Et c'est vrai, c'est un problème de l'œuf et de la poule et on résout ça dans le DNS en mettant quand même dans la zone parent les enregistrement A et AAAA des serveurs DNS faisant autorité sur notre zone, en plus des enregistrements NS.

Cela se passe souvent dans l'interface du bureau d'enregistrement où on renseigne les noms et IP dans des champs Glue Record.

•.nom : Un nom de domaine relatif au $ORIGIN de la zone ou un FQDN.
•.TTL (Time To Live) (facultatif) : La durée en seconde durant laquelle l'enregistrement devrait être conservé dans le cache d'un résolveur ("devrait" car les administrateur⋅ice⋅s de résolveurs peuvent choisir de changer cela).
•.Classe : Il en existe plusieurs mais c'est majoritairement IN pour INternet qui est utilisé (Cf. Section 3.2 du RFC 6895).
•.Type : Indique le type de l'enregistrement, il en existe plusieurs.
•.Taille (facultatif) : La taille en octets du champs Donnée.
•.Donnée : L'information que l'on souhaite associer au champ et qui dépend du Type (Du texte, une adresse IPv4 ou IPv6, un nom, etc)

Pour expliquer rapidement ce que l'on voit au début du fichier (Cf section 5 du RFC 1035) :

•.$ORIGIN : C'est le FQDN de la zone (qui nous permet d'écrire des noms relatifs à celui-ci par la suite).
•.$TTL : Le TTL par défaut s'il n'est pas précisé dans un enregistrement.

Donc pour mettre à jour notre zone DNS il nous suffit de modifier le fichier puis de dire à NSD de recharger la zone, avec la commande :

$ nsd-control reload lithio.fr

Le serial

Vous avez surement remarqué que dans l'enregistrement SOA de notre zone la troisième valeur se nomme serial. Il s'agit du numéro de version de notre fichier de zone, il faut donc l'incrémenter à chaque modification du fichier.

Il ne faut surtout pas oublier de le faire sans quoi les serveurs secondaires ne voudront pas récupérer la nouvelle version de la zone.

Quant à quoi mettre comme serial, la section 2.2 du RFC 1912 recommande d'utiliser la date du jour suivie d'un nombre (YYYYMMDDnn).

Tester

On peut facilement tester que tel ou tel serveur réponde bien avec un outil comme Drill :

$ drill @ns1.lithio.fr A lithio.fr

;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 38363

;; flags: qr aa rd ; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4

;; QUESTION SECTION:

;; lithio.fr. IN A

;; ANSWER SECTION:

lithio.fr. 3600 IN A 51.254.121.3

;; AUTHORITY SECTION:

lithio.fr. 3600 IN NS ns1.lithio.fr.

lithio.fr. 3600 IN NS ns2.lithio.fr.

;; ADDITIONAL SECTION:

ns1.lithio.fr. 3600 IN A 51.254.121.3

ns2.lithio.fr. 3600 IN A 80.67.176.37

ns1.lithio.fr. 3600 IN AAAA 2001:41d0:401:3000::b8a

ns2.lithio.fr. 3600 IN AAAA 2001:910:1025:1::1

;; Query time: 21 msec

;; SERVER: 51.254.121.3

;; WHEN: Fri Jan 17 14:47:53 2020

;; MSG SIZE rcvd: 167

Conclusion

Au final malgré la quantité d'informations, gérer ses serveurs DNS faisant autorité est plutôt simple. La partie plus complexe arrive quand on souhaite ajouter de la sécurité avec DNSSEC (ce qu'il faut faire) mais ça fera l'objet d'un prochain article.

Signer sa zone DNS avec OpenDNSSEC

Publié le 19/05/2020

Aujourd'hui nous allons voir comment signer notre zone DNS avec DNSSEC, car gérer son DNS faisant autorité c'est rigolo mais y ajouter DNSSEC ça l'est aussi. DNSSEC est le protocole qui permet de sécuriser les données du DNS en signant cryptographiquement les enregistrements de zone DNS.

Je ne vais pas lister ici les bonnes raisons de signer sa zone avec DNSSEC car il existe de nombreux articles sur le sujet et en 2020 un ou une bon⋅ne adminsys sait qu'il faut signer ses zones. Il existe également de bons articles techniques (attention toutefois à bien vérifier la version d'OpenDNSSEC utilisée car les commandes, entre autres, changent entre la version 1 et 2) utiles à lire.

Si vous utilisez FreeBSD, cet article est également disponible sur https://adminblog.foucry.net/posts/info/dnssec/.

Mini-introduction à DNSSEC

Le but de DNSSEC est que l'utilisateur final (ou plutôt son résolveur) puisse établir une chaîne de confiance entre la racine (en qui le résolveur a déjà confiance car il en connaît les clés au démarrage) et le DNS faisant autorité sur la zone lui donnant la réponse à sa requête.

En théorie le fonctionnement est le suivant :

•.Chaque zone signe ses enregistrements DNS avec une clé
•.La zone parente possède un enregistrement DNS qui contient le hash de la clé dont la zone enfant se sert pour signer
•.Comme on a confiance dans les clés de la racine, on peut vérifier toute la chaîne jusqu'aux enregistrements signés par la clé finale

Par exemple pour lithio.fr :

•.On a confiance dans les clés A de la racine et celle-ci signe ses enregistrements avec.
•.On interroge la racine qui nous dit d'aller interroger les DNS de fr.
- •.La racine a aussi un enregistrement qui indique que fr signe avec une clé B
•.On interroge fr qui nous dit d'aller interroger les DNS de lithio.fr.
- •.fr a aussi un enregistrement qui indique que lithio.fr signe avec une clé C.
•.On interroge lithio.fr qui nous donne notre réponse en signant avec sa clé C

Au final on a donc la racine qui signe ses réponses avec la clé A, fr qui signe ses réponses avec la clé B et lithio.fr qui signe ses réponses avec la clé C. On a de base confiance en A, A a confiance en B et B a confiance en C : ainsi on fait confiance aux réponses de lithio.fr via toute la chaîne.

Cet exemple sert juste d'explication car dans les faits chaque zone n'a pas une clé mais plusieurs : les KSK (Key Signing Keys) et les ZSK (Zone Signing Key). Les KSK sont comme les clés A, B et C de notre exemple sauf qu'au lieu de signer directement les enregistrements DNS de la zone, elles vont signer des ZSK qui, elles, vont signer les enregistrements de la zone. La chaîne de confiance suit toujours le même principe sauf qu'il y a plus d'élements. À noter que les hash de la clé fille dans la zone parente sont appelés DS (Delegation Signer).

Pour prendre un exemple concret :

dnssec-lithiofr

Schéma DNSSEC de lithio.fr

Dans ce schéma qui représente la chaîne DNSSEC jusqu'à lithio.fr :

•.On a confiance dans la clé qui a l'id 20326 de la racine.
•.On interroge la racine qui nous dit d'aller interroger les DNS de fr.
- •.La racine a bien la clé 20326 qui signe la clé 22545
- •.La racine a aussi un enregistrement DS signé par 22545 qui indique que fr signe avec la clé 35095
•.On interroge fr qui nous dit d'aller interroger les DNS de lithio.fr.
- •.fr a bien la clé 35095 qui signe la clé 28756
- •.fr a aussi un enregistrement DS signé par 28756 qui indique que lithio.fr signe avec la clé 65035.
•.On interroge lithio.fr
- •.lithio.fr a bien la clé 65035 qui signe la clé 6378
- •.lithio.fr nous donne la réponse à notre requête en signant cette réponse avec la clé 6378

On peut également voir cette arborescence en utilisant drill :

$ drill -S lithio.fr SOA

;; Number of trusted keys: 2

;; Chasing: lithio.fr. SOA

DNSSEC Trust tree:

lithio.fr. (SOA)

|---lithio.fr. (DNSKEY keytag: 6378 alg: 8 flags: 256)

|---lithio.fr. (DNSKEY keytag: 65035 alg: 8 flags: 257)

|---lithio.fr. (DS keytag: 65035 digest type: 2)

|---fr. (DNSKEY keytag: 28756 alg: 8 flags: 256)

|---fr. (DNSKEY keytag: 35095 alg: 8 flags: 257)

|---fr. (DS keytag: 35095 digest type: 2)

|---. (DNSKEY keytag: 22545 alg: 8 flags: 256)

|---. (DNSKEY keytag: 20326 alg: 8 flags: 257)

;; Chase successful

Ainsi, en ayant confiance uniquement en une clé de la racine, on peut vérifier les réponses de toute la chaîne.

Pour commencer

Dans cet article nous allons nous intéresser uniquement à la dernière partie (avec lithio.fr). Notre but va être de générer une KSK, de transmettre le DS à la zone parente pour que celle-ci puisse dire que l'on signe avec cette KSK, et d'utiliser la KSK pour signer des ZSK qui vont elles-mêmes signer les enregistrements DNS de notre zone.

Dans cet article je pars du principe que vous gérez déjà votre propre DNS faisant autorité (avec Bind ou NSD par exemple).

Dans le cadre des tests de cet article j'utilise des machines sous Debian 10 et nous allons signer la zone dnssec.lithio.fr (créée et active uniquement pour ces tests), cette zone ainsi que sa zone parente lithio.fr sont gérées par le logiciel NSD.

Nous allons donc devoir :

•.Installer les programmes utiles
•.Configurer SoftHSM (notre stockage de clés)
•.Configurer OpenDNSSEC
•.Ajouter notre zone à OpenDNSSEC
•.Publier notre zone
•.Transmettre le DS à la zone parente
•.Signer notre zone

Installation des paquets

On installe OpenDNSSEC et SoftHSM2 :

# apt install opendnssec softhsm2

OpenDNSSEC est le logiciel qui va s'occuper de la signature de la zone, la génération et la rotation des clés en suivant une politique que nous lui indiquerons. SoftHSM2 est un HSM logiciel (car nous n'avons pas de HSM matériel), SoftHSM est utilisé pour stocker des clés cryptographiques.

Configuration de SoftHSM

On crée un slot HSM sur le slot 0 avec l'étiquette (TokenLabel) OpenDNSSEC, il nous demande un code pin administrateur et utilisateur (je mets 1234 pour l'exemple mais bien sûr il faut en mettre des plus sûrs).

# softhsm2-util --init-token --slot 0 --label "OpenDNSSEC"

=== SO PIN (4-255 characters) ===

Please enter SO PIN: ****

Please reenter SO PIN: ****

=== User PIN (4-255 characters) ===

Please enter user PIN: ****

Please reenter user PIN: ****

The token has been initialized and is reassigned to slot 364027858

On peut vérifier les informations avec la commande suivante.

# softhsm2-util --show-slots

Available slots:

Slot 364027858

Slot info:

Description: SoftHSM slot ID 0x15b29fd2

Manufacturer ID: SoftHSM project

Hardware version: 2.4

Firmware version: 2.4

Token present: yes

Token info:

Manufacturer ID: SoftHSM project

Model: SoftHSM v2

Hardware version: 2.4

Firmware version: 2.4

Serial number: 6b9fa0e695b29fd2

Initialized: yes

User PIN init.: yes

Label: OpenDNSSEC

Configuration d'OpenDNSSEC

OpenDNSSEC contient 2 outils principaux qui nous intéressent : "l'enforcer" et "le signer".

L'enforcer s'occupe de faire appliquer les politiques et le signer, et bien, signe.

Configuration générale

En éditant /etc/opendnssec/conf.xml.

On modifie le bloc du HSM pour indiquer à OpenDNSSEC où sont stockées nos clés ainsi que le pin :

<Module>/usr/lib/softhsm/libsofthsm2.so</Module>

<TokenLabel>OpenDNSSEC</TokenLabel>

</Repository>

On ne touche pas à la configuration Common qui est bien comme elle est.

Les clés (surtout les ZSK) sont régulièrement changées, le logiciel en génère donc à l'avance pour assurer le remplacement de manière fluide. On va modifier la configuration de l'enforcer, pour générer nos clés 1 jour en avance.

<Datastore><SQLite>/var/lib/opendnssec/kasp.db</SQLite></Datastore>

<WorkingDirectory>/var/lib/opendnssec/enforcer</WorkingDirectory>

</Enforcer>

On va modifier la configuration du signer pour signaler - une fois la zone signée - à NSD de recharger la zone (à adapter en fonction du logiciel que vous utilisez).

<WorkingDirectory>/var/lib/opendnssec/signer</WorkingDirectory>

<!-- the <NotifyCommmand> will expand the following variables:

%zone the name of the zone that was signed

%zonefile the filename of the signed zone

-->

<NotifyCommand>/usr/sbin/nsd-control reload %zone</NotifyCommand>

</Signer>

On constate également qu'il n'y a pour le moment aucune clé générée :

# ods-hsmutil list

Listing keys in all repositories.

0 keys found.

Repository ID Type

---------- --

Configuration Kasp

KASP pour "Key And Signature Policy" est la configuration qui contient les politiques de génération et renouvellement des clés. Le mieux pour bien en comprendre le fonctionnement est d'en lire la documentation.

On va modifier /etc/opendnssec/kasp.xml.

Nous devons ici éditer la configuration que nous allons utiliser, il y en a de base 2 : default (qui a d'ailleurs comme description A default policy that will amaze you and your friends, comme quoi on rigole bien dans le monde du DNS) et lab. Dans le cadre de ce test je vais utiliser lab, mais en production il est préférable d'en utiliser d'autres, si, par exemple, vous souhaitez signer un domaine dont la zone parente est fr, l'AFNIC à mis à disposition un document sur le sujet.

On voit également qu'on peut indiquer les algorithmes utilisés pour générer les clés, par défaut c'est le 8 (RSA-SHA256) qui est utilisé. Pour savoir quoi mettre la section 3.1 du RFC 8624 est bien utile en nous donnant un tableau qui contient les algorithmes que l'on doit, ne doit pas ou devrait employer. Je vais utiliser ici le 13 (ECDSAP256SHA256) et indique que le renouvellement de la KSK est manuel (car il faudra l'envoyer à la zone parente à la main) :

<KSK>

<Repository>SoftHSM</Repository>

</KSK>

<ZSK>

<Repository>SoftHSM</Repository>

</ZSK>

À noter que dans ce fichier les périodes de temps sont indiquées au format ISO 8601 (comme expliqué dans la documentation). À noter également que les valeurs sont fixes : 1Y (un an) vaudra toujours 365 jours, même les années bissextiles; 1M (un mois) vaudra toujours 31 jours, même en février.

On vérifie que notre configuration soit correcte :

# ods-kaspcheck

On initialise la base de données de l'enforcer avec la commande (on ne le fait que la première fois, plus jamais ensuite) :

# ods-enforcer-db-setup

On supprime le fichier /etc/opendnssec/prevent-startup qui empêche le lancement d'OpenDNSSEC tant que celui-ci n'est pas configuré et on lance l'enforcer et le signer DNSSEC :

# systemctl start opendnssec-enforcer

# systemctl start opendnssec-signer

On importe nos politiques :

# ods-enforcer policy import

Normalement tout est prêt pour commencer à gérer nos zones.